Amendment in Response to December 19, 2005 Office Action 
Application No. 09/785,596 
Docket No. 6208-003 



Remarks 

The undersigned's Remarks are preceded by related comments of the Examiner, presented in 
small bold-faced type font. 

Claim rejections - 35 USC § 112 

Claim 1 rejected under 35 U.S.C. § 112, second paragraph, as being indefinite for failing to 
particularly point out and distinctly claim the subject matter which applicant regards as the 
invention. Claim 1 recites a "system for managing transactional information." The claimed 
system is comprised of a party file, an account file, and a transaction file. Claims 1-10 do not 
recite the function or use of any system, or how the system uses said files. 

Applicants have amended claims 1-10 to comply with 35 § USC 101 (see below). Claims 1-10 are now 
drawn to "A computer-readable medium encoded with a data structure for managing transaction 
information". The computer-readable medium encoded with the data structure recited in the claim, is 
used "for managing transaction information" in the manner disclosed in the specification. Applicants 
respectfully submit that this rejection is now overcome. 



Claim rejections - 35 USC § 101 

Claims 1-10 rejected under 35 U.S.C. 101 because the claimed invention is directed to non- 
statutory subject matter. The party file, account file, and transaction file recited in claims 1- 
10 are not statutory because they are not capable of causing functional change in the 
computer. Such claimed data structures do not define any structural and functional 
interrelationships between the data structure and other claimed aspects of the invention 
which permit the data structure's functionality to be realized (MPEP § 2106). 

Applicants have hereby amended claims 1-10 to comply with 35 § USC 101. Applicants respectfully 
submit that this rejection is now overcome. 



Claim rejections - 35 USC § 102 

Claims 1, 11 and 21 rejected under 35 U.S.C. 102(a) as being anticipated by Cochrane et al. 
U.S. Patent No. 6,460,027. Cochrane discloses a credit card company storing credit card 
customer information, their credit card accounts, and transactions that customers made. 
Cochrane describes the "database schema" as having a customer information table, an 
account information table, and a transaction information table (column 5, lines 47-58), each 
account record in the account information table having a link to a customer record in the 
customer information table (column 6, line 18), and each transaction record in the 
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transaction information table having a link to an account in the account information table 
(column 6, line 35). 

The Examiner's rejection is respectfully traversed. Contrary to the Examiner's suggestion, 
Cochrane does not teach a computer-readable medium encoded with a data structure for managing 
transaction information, a method for managing transactional information, or a method of using a 
computer for managing transactional information, as recited by claims 1,11, and 21, respectively. 

To support a rejection under § 102(a), the cited prior art of reference must disclose each element 
of the rejected claim in the manner recited by the claim. Cochrane, however, does not disclose at least the 
elements of claims 1,11 and 21 "each of said plurality of party records having party information relating 
to one of a plurality of parties". In Cochrane's disclosure, the customer information table does not have a 
link to at least another customer. Claims 1, 11 and 21 require that each party record have party 
information relating to one of a plurality of parties. This is exemplified in Figures 2, 3A and 3B of 
Applicants disclosure. For at least the reason that the Examiner has not shown that Cochrane teaches or 
suggests these limitations, a § 102(a) rejection of claims 1, 11 and 21 in light of Cochrane is not 
supported. It is respectfully requested that the Examiner withdraw the rejection. 



Claim rejections - 35 USC § 103 

Claims 2-6 and 12-16 rejected under 35 U.S.C. 103(a) as being unpatentable over Cochrane. 
Cochrane teaches account records being linked to party records. Cochrane fails to teach said 
party records containing fields for principle party, order placer party, salesperson party, 
booking company party, and guarantor party. Official notice is taken that it is old and well 
known in the art that in a database structure, records may have any number of fields 
containing information pertaining to said records* The parties of claims 2=6 and 12-16 
represent the Applicants' intended use. Therefore, it would be obvious to one of normal skill 
in the art to include any fields within each party record, which are required for the 
database's intended use and operation. 

The Examiner's rejection is respectfully traversed. The Examiner states that "Cochrane fails to 
teach said party records containing fields for principle party, order placer party, salesperson party, 
booking company party, and guarantor party" and that "it would be obvious to one of normal skill in the 
art to include any fields within each party record, which are required for the database's intended use and 
operation". Applicants respectfully submit that this argument is inappropriate to justify the Examiner's 

10 

NYA 777281.1 



Amendment in Response to December 19, 2005 Office Action 
Application No. 09/785,596 
Docket No. 6208-003 

rejection, since the "database's intended use and operation" are part of Applicants' invention and cannot 
be considered obvious. 

As recited by the MPEP: 

"The initial burden is on the examiner to provide some suggestion of the desirability of doing 
what the inventor has done. 'To support the conclusion that the claimed invention is directed to 
obvious subject matter, either the references must expressly or impliedly suggest the claimed 
invention or the examiner must present a convincing line of reasoning as to why the artisan 
would have found the claimed invention to have been obvious in light of the teachings of the 
references. "Ex parte Clapp, 227 USPQ 972, 973 (Bd. Pat. App. & Inter. 1985). " 

"When applying 35 U.S.C. 103, the following tenets of patent law must be adhered to:(...) 

(C) The references must be viewed without the benefit of impermissible hindsight vision 
afforded by the claimed invention (...) 

Hodosh v. Block Drug Co., Inc., 786 F.2d 1136, 1143 n.5, 229 USPQ 182, 187 n.5 (Fed, Cir. 
1986). " 

In the Background section of the Application, Applicants describe the deficiencies in the data 
structures of the prior art, which limit the operability and efficiency of databases managing financial 
accounts. Part of Applicants' invention is to establish specific links between determined records to allow 
for new operability of the databases and consequently, improved efficiency. In other words, the intended 
use of Applicants' database did not exist prior to Applicants' invention. In particular, claims 2-6 and 12- 
16, which depend either directly or indirectly from claims 1 or 1 1, require that "each of said plurality of 
party records having party information relating to one of a plurality of parties", which as explained 
earlier, is not taught by Cochrane. Therefore, adding any fields within each party record, when the 
limitations "each of said plurality of party records having party information relating to one of a plurality 
of parties" are not met, cannot be rendered obvious. It is further submitted that the Examiner's rejection 
appears to be based on impermissible hindsight reasoning. 



Claims 7-10 rejected under 35 U.S.C. 103(a) as being unpatentable over Cochrane as applied 
to Claim 1 above, and further in view of Bromley et al. U.S. Patent No. 5,819,263. Cochrane 
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fails to teach party records having a hierarchical relationship field that relates a first party 
to a second party. Bromley discloses a financial planning system incorporating relationship 
and group management, organizing client, account, and transaction information in a 
database structure, containing client and transaction records. Bromley teaches each person 
or organization is assigned a client ID, and may have a unique role or relationship with 
another person or organization, for example as a mother and daughter (column 14, lines 29- 
45). These relationships are defined by organizing parties into groups, and assigning group 
IDs to individual parties. 

It would be obvious to one skilled in the art at the time of the Applicants' invention to 
include the group ID field for defining hierarchical relationships in the system and method 
described by Cochrane, in order to "provide efficient customer service," to "avoid sending 
duplicate correspondence," to "improve speed of the system", and for "responding to special 
requests" which are all desirable traits of such a system (Bromley, column 14, lines 55-67). 

Examiner notes that guarantor-guarantee relationship in claim 10 is recited as intended use 
only, and is therefore anticipated by the teachings of Bromley. 



Applicants respectfully traverse the Examiner's rejection. As explained earlier, Cochrane does 
neither anticipate nor render obvious the invention of claim 1, from which claims 7-10 depend, either 
directly or indirectly. 

Even if there was a motivation to combine Cochrane and Bromley, the combination of both 
references would not teach or suggest all the claim limitations of claims 7-10, since Bromley does not 
disclose at least a "hierarchical relationship field". Bromley discloses a data structure where "every 
contact classified as a PERSON or ORGANIZATION is preferably in a GROUP" (col. 14, lines 51-53). 
Bromley adds "In a preferred embodiment, for an advisor to provide efficient customer service, these 
parties are organized into GROUPs. Grouping the parties allows an advisor to avoid sending duplicate 
correspondence to related people or organizations. To improve the speed of the system, grouping also 
eliminates duplicate address fields in the database. Furthermore, the grouping of parties allows an advisor 
to respond to special requests from individual parties. For example, after two people go through a divorce, 
each of the people typically request separate statements to be sent to separate addresses. The grouping of 
clients, along with relationship fields, allows an advisor to efficiently respond to this request" (col. 14, 
lines 55-67). Therefore, Bromley discloses the use of a "unique group ID", Bromley does not disclose a 
"hierarchy relationship field", as described in Applicants' specification: 

"In addition to establishing party relationships as described above, party record 3 includes a 
hierarchical relationship field 27 for identifying parties that are related to each other in a 
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hierarchical structure. Hierarchical relationship field 27 consists of an HQ1 field 27 A and an HQ2 
field 27B. Hierarchical relationship field 27 is used as follows. Assume the party of party record 
3(6) is a corporation and that corporation owns a subsidiary corporation that is a party stored in 
party record 3(4). Assume further that the corporation of party record 3(4) owns a subsidiary 
corporation that is a party stored in party record 3(1). To identify that these three corporations are 
all related entities (which may not be apparent from the party names), a link is placed in HQ1 field 
27A(1) of party record 3(1) pointing to HQ2 field 27B(4) of party record 3(4) that indicates that 
the party of party record 3(4) is the parent of the party of party record 3(1). Similarly, a link is 
placed in HQ1 field 27A(4) of party record 3(4) pointing to HQ2 field 27B(6) of party record 3(6) 
that indicates that the party of party record 3(6) is the parent of the party of party record 3(4). 
When the tree structure defined by the links stored in hierarchical relationship fields 27(1), 27(4) 
and 27(6) is traversed, the hierarchical relationship between the three corporations is determined, 
as shown in FIG. 3B. As will be shown later, determining the hierarchical relationship between 
parties is necessary to effectively perform risk management and profitability analysis. 

Although the creation of party relationships and hierarchical relationships has been 
shown using links placed in party relationship field 29 and hierarchical relationship field 27, 
respectively, to create a tree structure to identify the desired relationships, it will be understood by 
one possessing ordinary skill in the art that any other technique to identify the party and 
hierarchical relationships between the parties may be used. Additionally, the system has the 
ability to maintain multiple hierarchies." (page 12) 

The Examiner refers to the example given in Bromley of a mother/daughter relationship existing 
between two persons. A "relationship" is not equivalent to a "hierarchical relationship". There is no 
hierarchy implied in the example provided by Bromley that corresponds to the hierarchical relationship as 
described in the Applicants' disclosure. Bromley groups clients to avoid duplicating correspondence and 
to simplify the database. Bromley does not teach to record a hierarchy within a group of clients. 

With respect to relationships, Applicants describe relationships that for example are established 
between different parties that can be a corporation and a person: 

"Referring now to FIG. 4, there is shown a block diagram of party file 3 showing relationships 
between particular party records 3(x). Each party record 3(x) also includes a party relationship 
field 29 that facilitates the creation of relationships between different parties stored in party file 3. 
For example, if XYZ Corp. is a party stored in party record 3(5) and Mr. Smith, a board member 
of XYz, Corp. is a party stored in party record 3(7), it is useful to identify Mr. Smith as a board 
member of XYZ Corp. so that his obligations with respect to buying/selling XYZ Corp. stock are 
not violated. To create such a relationship between XYZ Corp. and Mr. Smith, party relationship 
field 29(5) of party record 3(5) will contain a link, using known database programming 
techniques, to party record 3(7) identifying that party as a board member of the party contained in 
party record 3(5). Also, party relationship field 29(7) of party record 3(7) will contain a link to 
party record 3(5) identifying that party as a company that the party contained in party record 3(7) 
is a board member of." (page 1 1) 

Bromley teaches away from this kind of relationship, since it teaches that "Each person is 
assigned a CLIENT ID and may have a unique role or relationship with other PERSONS" (col 14., lines 
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37-39) and "Each ORGANIZATION is assigned a CLIENT ID, and in an alternative embodiment, has a 
unique relationship with other ORGANIZATIONS" (col 14, lines 48-51). 

For the foregoing reasons, claims 7-10 cannot be obvious in view of Cochrane and Bromley. 
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Closing 

Claims 1-10 have been amended. Claims 1-21 are now pending and believed to be in condition 
for allowance. Applicants respectfully request that all pending claims be allowed. 

Please apply any credits or excess charges to our deposit account number 50-0521. 




Customer No. 27383 
Telephone: (212) 895-1376 
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